5.3.3 APPX Application Design Manual

+ Chapter 1-1: Overview of Application Design
+ Chapter 1-2: Getting Started
- Chapter 1-3: Data Dictionary
+ Chapter 1-4: Understanding Process Design
+ Chapter 1-5: Interprocess Communication
+ Chapter 1-6: Customizing Your Application
+ Chapter 1-7: The Documentation Facility
+ Chapter 1-8: Application Design Tools
+ Chapter 2-1: Data Dictionary Overview
+ Chapter 2-2: Data Dictionary Concepts
+ Chapter 2-3: Domains
+ Chapter 2-4: Files and Fields
+ Chapter 2-5: Work Fields
+ Chapter 3-1: Overview of APPX Processes
+ Chapter 3-2: Getting Started
+ Chapter 3-3: Process Definition
+ Chapter 3-4: Menu Processes
+ Chapter 3-5: Job Processes
+ Chapter 3-6: Input Processes
+ Chapter 3-7: Output Processes
+ Chapter 3-8: Update Processes
+ Chapter 3-9: Query Processes
+ Chapter 3-10: Inquiry Processes
+ Chapter 3-11: Status Processes
+ Chapter 3-12: Subroutine Processes
+ Chapter 3-13: Table Processes
+ Chapter 3-14: Automatic and Optional Children
+ Chapter 3-15: Using the Image Editor
+ Chapter 3-16: Using GUI Features of the Image Editor
+ Chapter 3-17: Using Event Points
+ Chapter 4-1: ILF Integration
+ Chapter 4-2: True/False Status Indicators
+ Chapter 4-3: Specifying Statements
+ Chapter 4-4: The ILF Editor
+ Chapter 4-5: The Appx ILF Debugger
+ Chapter 4-6: ILF Keyword Reference
+ Chapter 4-7: Predefined Fields
+ Chapter 4-8: Runtime Subroutine's and Predefined Processes
+ Chapter 4-9: Appx Chart Director API

Chapter 1-3: Data Dictionary

Security in the Data Dictionary


Within the APPX data dictionary, you use field and record security specifications to control which users can view and modify data presented on images in applications.

To secure fields on input and output images, you assign a read rights security code. Read rights govern whether or not a user can see the contents of a field as defined on an image either input (transaction entry or maintenance screens, for example) or output (journals, lists, or reports). If a user does not have read rights to a secured field, the contents of the field are invisible and non-editable. Refer to the discussion on Database Security for more information.

Field security specifications, unlike record security specifications, do not restrict access to fields when developing or modifying an application within application design. For example, a designer can define statements to modify values in secured fields, or to load the contents of secured fields into unsecured fields. The contents of a secured record, however, cannot be accessed or modified with statements.

You define read and modify security specifications for each of the following components of the dictionary:

Domain security specifications cannot be overridden for any domain-type fields and work fields that reference them.

File security specifications control read and write access to files.

Field security specifications control read and write access to fields. If security specifications are blank, access to the field is unrestricted.

Work field security specifications control read and write access to work fields. If security specifications are blank, access to the work field is unrestricted.

In addition to the file/field-level security described above, you can establish record-level security as described in the next section.

Application Design Manual                                         "Powered by Appx Software"

58

©2006 By APPX Software, Inc. All Rights Reserved